Date: Sun, 30 Oct 94 04:30:02 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: List Subject: TCP-Group Digest V94 #243 To: tcp-group-digest TCP-Group Digest Sun, 30 Oct 94 Volume 94 : Issue 243 Today's Topics: If they're gonna sell frequencies, what about these? PacComm HandiPacket (2 msgs) tftp/udp and a defect in bind Users and 9600 baud Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 29 Oct 1994 11:13:38 -0700 (PDT) From: California Wireless Incorporated Subject: If they're gonna sell frequencies, what about these? Fred R. Goldstein fgoldstein@bbn.com writes: >I am not nearly as up in arms about this as many hams... > >How cum? Look... do any of you USE any of that frequency band? >... (Stuff deleted) >We do such a bad job with the space we have I just can't get all >upset about this, so long as we end up with a few usable chunks. >... (Stuff deleted) It is certainly true that some hams won't care about the future of ham radio, and won't care about experimentation with new and interesting modes, or about succeeding generations. Some will be happy with their local 2m repeater and won't need more. Some think that if you don't work it on HF, it doesn't matter. That's OK, ham radio is a diverse hobby, but we're all bonded by one thing: our need of frequencies upon which we can transmit! So, Fred, you may not have 2.4 GHz gear, or work Mode S, or be experimenting with wide-band spread spectrum, or using your local ATV repeater with an S band output, or... That's OK! But, please, Fred, don't write the FCC and tell them that you agree with their current ham frequency grab. Please. The way I see it, the FCC (and Hundt and his band of Beltway Bandits) is trying to get the golden eggs without the goose. The goose (Ham Radio) lays the Golden Eggs (Trained engineers, technicians, enthusiasts available for the commercial industry). The FCC, not happy with waiting for these eggs to be laid, instead wants to take a butcher knife and slice the goose open and get all of those golden eggs out. Of course, all they will end up with is a dead goose, and no golden eggs. But, presumably, the folks at the FCC never went through childhood and learned the moral of this story... I wonder what Hiram Percy Maxim would think! -Mike k3mc ------------------------------ Date: Sat, 29 Oct 1994 15:47:37 -0500 (CDT) From: Gerald J Creager Subject: PacComm HandiPacket I've misplaced my book, and need a little help, if someone might have the data available. I need to get the pin-out for the mini-DIN connector, so I can try to get the Bovine Positioning System prototype up this weekend. Thanks for the help, Gerry N5JXS gerry@cs.tamu.edu ps: Sorry Bruce, tamoo.edu was nix'd gc ------------------------------ Date: Sat, 29 Oct 1994 21:11:01 +0100 From: "Brian A. Lantz" Subject: PacComm HandiPacket On Sat, 29 Oct 1994, Gerald J Creager wrote: > I need to get the pin-out for the mini-DIN connector, so I can try to get the > Bovine Positioning System prototype up this weekend. Here, you go! We definitely want to keep that project MOO-ving ;-) Pin 1 - Ground for both audio and PTT Pin 2 - Audio output from the HandiPacket to the transmitter Pin 3 - SPecial 'resistor' line for hand held radios Pin 4 - Digital data input from external modem Pin 5 - Push-to-talk to allow keying the transmitter Pin 6 - Transmit clock signal (X16) for external modem Pin 7 - Receive audio from the receiver speaker or auxiliary jack to the HandiPacket Pin 8 - Digital data output for external modem ----------------------------------------------------------- Brian A. Lantz/KO4KS brian@lantz.com REAL PORTION of Microsoft Windows code: while (memory_available) { eat_major_portion_of_memory (no_real_reason); if (feel_like_it) make_user_THINK (this_is_an_OS); gates_bank_balance++; } ------------------------------ Date: Sat, 29 Oct 94 10:42:49 PDT From: Glenn Engel Subject: tftp/udp and a defect in bind Phil, In implementing tftp I discovered a slight problem. The code uses the following sequence: socket() bind() sendto() While this works fine with unix systems, it does not work right with NOS. The problem arises from the fact that bind does not assign a local port so packets go out with a local port of 0 and the remote machine never replies since the port is zero. The hp-ux man page states: When binding an AF_INET socket, sin_port can be a port number, or it can be zero. If sin_port is zero, the system assigns an unused port number automatically. I fixed this for udp with the following patch. -- Glenn Glenn Engel / glenne@lsid.hp.com / Hewlett Packard / LSID / NN7N / 206-335-2066 *** /usr/tmp/fdif1AAAa04108 Sat Oct 29 13:30:00 1994 --- udpsock.c Sat Oct 29 13:16:33 1994 *************** *** 29,34 **** --- 29,38 ---- s = up->index; sp = (struct sockaddr_in *)up->name; + + /* If the call to bind specifies a local port of 0, assign one now */ + if (sp->sin_port == 0) sp->sin_port = Lport++; + lsock.address = sp->sin_addr.s_addr; lsock.port = sp->sin_port; up->cb.udp = open_udp(&lsock,s_urcall); ------------------------------ Date: Sat, 29 Oct 94 13:25:30 From: kz1f@RELAY.HDN.LEGENT.COM Subject: Users and 9600 baud Karl wrote: "So lets admit that the new no code ham is.." ~incapable of running at because they won't have a scope or deviation meters.. Come on... I used to do 22 wpm and passed the novice, tech, advanced and extra written exams. I happen to have a scope but do not have deviation meters or a sophisticated test bench. I dont home brew and that has absolutely nothing to do with how fast my code is. It is absolutely FM (and the m stands for magic) that I got 5, much less 22 wpm on code. And that had absolutely nothing to do with my knowledge of theory or electronic design or knowledge of radio signal propagation. Notice, I didnt get gen, I got tech; I didnt get extra, I got adv. <- points to code, doesnt it. I think the issue of code vs no-code is settled. There are alot of lurkers on this group that are quite skilled in networking and/or radio theory and/or pratical electronics that couldnt muster 1 wpm of morse code. They may be absolutely brilliant at setting up really high speed radio links. Perhaps what Karl (and 'we') ought to agree on, or argue over, is that 9600, or better, operation is not something the casual, or appliance, operator should get involved in. -Walt ------------------------------ End of TCP-Group Digest V94 #243 ******************************